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INTRODUCTION 


In June 1988, the National Aeronautics and Space Administration (NASA) Infor- 
mation Resources Management (IRM) Council established the Ada and Software 
Management Assessment Working Group (ASMAWG). The IRM Council directed 
the ASMAWG to assess the NASA posture on software management and Ada 
technology, define means to build NASA’s base of knowledge and experience in 
Ada and software engineering, and develop a plan for carrying NASA toward state- 
of-the-art software technology. The ASMAWG consisted of seven members and 
four advisors. It was chaired by Frank McGarry of Goddard Space Flight Center 
(GSFC). The ASMAWG produced two reports: Ada and Software Management in 
NASA: Assessment and Recommendations (March 1989) and NASA— Evolving to Ada: 
Five-Year Plan (April 1989). 

When McGarry presented his final briefing to the IRM Council in April 1989, the 
Council requested that he organize a symposium and forum to 

“a. Debrief all interested agency staff as to the basis for the findings and the 
Group’s rationale supporting the resulting recommendations; 

b. Provide an open forum to explore the many facets of the material cov- 
ered by the Group; and 

c. Provide any other material which agency staff might need in order to 
prepare comments on the Group’s proposal.” 

The symposium and forum were held at Goddard Space Flight Center in 
Greenbelt, Maryland, on May 31 and June 1, 1989. The symposium (first day) 
was devoted to McGarry’ s summary of the ASMAWG’ s findings and recommenda- 
tions and to responses by major NASA software contractors. The forum (second 
day) consisted of a series of panel discussions primarily involving representatives 
of NASA centers and headquarters. 

Noel Hinners, then chairman of the IRM Council, requested that by July 1989, 
attendees of the symposium and forum should submit comments on the 
ASMAWG’s reports to their IRM Council representative. The Council member will 
forward the comments to Wallace Keene, Executive Secretary of the ERM Council. 
Keene will consolidate the comments and formulate a collective response and rec- 
ommended action plan, which he will submit to the IRM Council. Hinners ex- 
pressed his hope that the IRM Council would adopt an action plan that responds to 
the reports by September 1989. 
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NASA 

National Aeronautics and 
Space Administration 

Washington, DC. » 
20546 

Office of the Administrator 


JUN 2 71968 



TO: NASA Information Resources Management (IRM) Council 

FROM: ADI/Chairman, NASA IRM Council 

StJBJECTz NASA IRM Council; Ada and Software Management 
Assessment Working Group 


* 


At the March 1988 meeting# the NASA IRM Council was advised that 
the Space Station Program has committed to use the Ada language 
for its flight systems and that the agency has a number of other 
ongoing Ada project and evaluation efforts. Concern was 
expressed that the agency may not have the necessary 
infrastructure to support using Ada. The Council was unaware of 
any comprehensive software management program or comparable Ada 
strategy to assure such an infrastructure is in place as needed 
by the agency. It was also observed that the agency has no 
coordinated strategy to leverage current Ada experiences for 
potential application on future projects. 

The Council recommended an appropriate group be appointed to 
assess the agency's ongoing and planned Ada activities and the 
infrastructure supporting software management and th§ Ada 
activities (present and projected) . As a result# I am 
establishing the Ada and Software Management Assessment Working 
Group made up of the following chairperson and members who have 
agreed to participate in this effort. 

Chairperson: 

Francis E. McGarry, Head# Systems Development Branch, Goddard 
Space Flight Center# Code 552 

Members : 

Donald W. Sova# Deputy Manager, Software Management Assurance 
Program# NASA Headquarters# Code QR 

John W. Wolfsberger# Systems Software Branch, Marshall Space 
Flight Center# Code EB42 

Robert A. Carlson# Manager, Software Services Contract# Ames 
Research Center, Code RCA 

Edward S. Chevers# Assistant Chief, Avionics Systems Division, 
Johnson Space Center# Code EH 
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Arthur I. Zygielbaum, Deputy Manager/ Information Systems 
Division/ Jet Propulsion Laboratory/ Code 360 

John L. Feagon, Chief, Software Engineering Office, Lewis 
Research Center, Code 4010 

The group should review the agency's software management programs 
and present an Ada implementation and use strategy appropriate 
for NASA over the next 5 years. I would like the group to 
present a report on its progress, including a schedule for 
completing the assessment, at the next NASA IRM Council meeting 
scheduled September 8, 1988. 



Distribution 
B/T. Campbell 
E/L. Fisk 
H/S. Evans 
M/R. Truly 
N/M. Peralta 
Q/G. Rodney 
R/W. Ballhaus 
S/J. Odom 
T/R. Aller 
ARC/D/D. Compton 
JPL/100/L . Allen 
JSC/AA/A . Cohen 

cct 

QR/D. Sova 
ARC/RCA/R. Carlson 
GSFC/100/J. Townsend 
GSFC/552/F . McGarry 
JPL/360/A . Zygielbaum 
JSC/EH/E. Chevers 
KSC/CD/F . McCartney 
LaRC/0100/R. Petersen 
LeRC/0100/J. Klineberg 
LeRC/4010/J • Feagon 
MSFC/DA01/J. Thompson 
MSFC/EB42/J « Wolfsberger 
SSC/AA00/J . Hlass 
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NASA 

National Aeronautics and 
Space Administration 

Washington. D C 

20546 MAY 

Office ot the Administrator 


TO: Off icials-In-Charge of Headquarters Offices 

Directors # NASA Field Installations 
Director , Jet Propulsion Laboratory 

FROMi ADA/Aaaociate Deputy Administrator 

SUBJECT* Ada and Software Management Assessment Symposium 


In March 1988 # the NASA Information Resources Management 
(XRM) Council chartered the Ada and Software Management 
Assessment Group (hereafter called the Group) under the 
leadership of Mr. Frank McGarry# Goddard Space Flight Center. 
The Group’s objectives were to assess the state of software 
management within the agency and the adequacy of the agency's 
Infrastructure supporting the Ada programming language and to 
recommend improvements in both areas # where indicated. The 
Group concluded its assessment this past March and reported 
its findings and recommendations to the Council on April 10, 
1989. 

The Group found# in general# that ample opportunities exist 
for effectively coping with the risks inherent in the 
changing environment of software technology# but that no 
organization was charte red to coordinate s uch effort s. As a 
consequence# the agency bears Increased risks of duplicating 
effort with minimum potential for leveraging our software- 
related investments. The Group observed that the agency's 
software costs have been increasing exponentially and placed 
the current software-related expenditures at approximately 
20 percent of the agency's budget. The Group further found 
that the agency may be unprepared to manage its current and 
planned Ada-based software development projects. The Group's 
findings are documented in the enclosed report entitled! 

"Ada and Software Management in NASAt Assessment and 
Recommendations." The Group's proposal for addressing their 
concerns is provided in the enclosed report# entitled! 
"NASA-Evolving to Ada: Five-Year Plan." 

It is apparent to the Council that NASA is on course which 
will lead# in due time, to the adoption of Ada for new 
mission software. This is not to say there won't be 
exceptions; however, given the direction of software 
management methodologies, the maturation of Ada-related 
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technologies, and a swelling Ada constituency (both in the 
public and private sectors) it is just a matter of time 
before the majority of the agency's programs and projects 
select Ada. The question, therefore, seems to be how best 
should the agency manage the evolution to Ada so that it will 
reap the maximum benefits, Zn this regard, it is absolutely 
necessary that NASA fully understand the attendant 
implications, risks, and challenges. 

To begin an agency dialogue on this subject, which I expect 
will lead to a comprehensive set of action plans, I have 
asked Mr. McGarry and the Group to conduct an Ada and 
Software Management Assessment Symposium. The purpose of the 
Symposium will be to: 

a. Debrief all interested agency staff as to the basis 
for the findings and the Group’s rationale supporting the 
resulting recommendations; 

b. Provide an open forum to explore the many facets of 
the material covered by the Group; and 

c. Provide any other material which agency staff might 
need in order to prepare comments on the Group's proposal. 

Mr. McGarry has scheduled the Symposium for May 31 and 
June 1, 1989, at the Goddard Space Flight Center in 
Greenbelt, Maryland. Your attendee (s) (both government and 
contractor personnel) should contact Mr. McGarry directly at: 

Mr. Frank McGarry 

NASA Goddard Space Flight Center (Code S52) 

Greenbelt, MD 20771 

(FTS) 888-6846 or (301) 286-6846. 

Mr. McGarry's staff will work directly with your attendee(s) 
regarding the agenda and associated logistics. 

Following the Symposium, Z would like your endorsement, 
comments, concerns, and recommendations regarding the Final 
Report and the Five-Year Plan. I would like your comments 
submitted in writing to the Council's Executive Secretary, as 
indicated below, by July 7, 1989: 

Mr. Wallace Keene 

Executive Secretary, NASA IRM Council 

NASA Headquarters (Code NT) 

Washington, DC 20546 
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Your comments will then be synthesized into a specific plan 
of action for review and endorsement by the 1RM Council and 
implementation by the Afdftey. - 

1 cannot over emphasize the importance of this Symposium and 
your comments in structuring a proper and measured agencywide 
response to this problem. We need your support# and I look 
to you to help ensure appropriate representation at the 
briefing. Additional copies of the final report and Five*’ 
Year Plan are available from Mr. McGarry. I remind you that 
both documents are the product of the Ada and Software 
Management Assessment Working Group and do not necessarily 
reflect NASA's official position* Please have your 
representatives contact Frank as soon as possible to schedule 
their attendance. 

^Noel W. Hinners 

2 Enclosures 
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FINAL AGENDA 


Ada AND SOFTWARE MANAGEMENT IN NASA 
SYMPOSIUM/FORUM 

MAY 31 AND JUNE 1, 1989 

NASA/GSFC 

BUILDING 3 AUDITORIUM 


Wednesday . Mav 31. 1989 
7:30 - 8:30 Registration 


8:30 - 10:30 


(Session 1) Findings and Recommendations Frank McGarry, 

of the ‘Ada and Software Manage- NASA/GSFC. 
ment Assessment Working Group’ Chair-ASMAWG 


10:30 - 11:00 Break 

11:00 - 12:00 (Session 2) Industry Perspective of Recommendations 


11:00 Review 1 Ray Woiverton and Bruce Krell/Hughes 
11:30 Review 2 Judy Fleming/IBM 


12:00 - 1:30 LUNCH 


1:30 - 3:00 


(Session 3) Industry Perspective of Recommendations 


1 :30 Review 3 
2:00 Review 4 
2:30 Review 5 


Dick Taylor/CSC 

Joe McCabe/McDonnell Douglas 

Mike Hollowich/TRW 


3:00 - 3:30 Break 


3:30 - 5:00 


(Session 4) Industry Perspective of Recommendations 


3:30 Review 6 
4:00 Review 7 
4:30 Review 8 


Jeff Neufeld/GE 

Kent Lennington/Lockheed 

Weldon Jackson/Boeing 


5:00 


ADJOURN - Day 1 


Thursday. June 

7:30 - 8:30 
8:30 - 10:15 


10:15 - 10:45 
10:45 - 12:15 


12:15 - 1:30 
1:30 - 3:00 


3:00 - 4:00 
4:00 


Ada AND SOFTWARE MANAGEMENT IN NASA 
SYMPOSIUM/FORUM 
(CONTINUED) 


L 19 89 


Refreshments 


(Session 5) PANEL/FORUM 

Potential Effects on NASA 
(Facilitator - Frank McGarry) 

Panelists: Jack Garman (JSC) 

Sue McMahon (HQ/OSSA) 
Tom Thornton (JPL) 

Rob Kudlinski (LaRC) 

Break 


(Session 6) PANEL/FORUM 

Potential Effects on NASA 
(Facilitator - Ed Seidewitz/GSFC) 


Panelists: John Dalton (GSFC) 

Debbie Hahn (KSC) 

Al Kopp (Telesoft, formerly DoD) 
Tony Carro (HQ/OSO) 

LUNCH 

(Session 7) PANEL/FORUM 

Potential Effects on NASA 
(Facilitator - Vic Basili/Univ. of MD) 

Panelists: Paul Smith (HQ/OAST) 

Dave Aichele (MSFC) 

Kathy Schubert (LeRC) 


Plenary Session - Summary (Facilitator - Frank McGarry) 

Panelists: Jack Garman (JSC) 

John Dalton (GSFC) 

Paul Smith (HQ/OAST) 

ADJOURN - Day 2 
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Ada AND SOFTWARE MANAGEMENT IN NASA SYMPOSIUM 


SESSION 1: ASMAWG FINDINGS AND RECOMMENDATIONS 
Frank McGarry 

Frank McGarry of GSFC, chair of the ASMAWG, opened the symposium on the 
first day by presenting a summary of the working group’s findings and recommen- 
dations. 

McGarry stated that the IRM Council commissioned the ASMAWG’s study to in- 
vestigate (1) the promises of Ada to improve software productivity and quality and 
(2) claims that a transition to Ada would require significant changes in NASA’s 
training programs and ways of doing business. In appointing the working group, 
IRM Council chair Noel Hinners said that the study should “assess the agency’s 
ongoing and planned Ada activities and the infrastructure supporting software 
management and the Ada activities (present and projected)” and that it “should 
present an Ada implementation and use strategy appropriate for NASA over the 
next 5 years.” 

McGarry noted that historically NASA has produced high-quality software, but that 
the amount and complexity of NASA’s software have been increasing greatly and 
that software engineering technology has been advancing rapidly. The increasing 
complexity of NASA’s missions, the expanded functionality of its software, and the 
huge amounts of data that this software must process suggest that some changes in 
the agency’s approach to software may be necessary. Although a number of indi- 
vidual projects, most notably the Space Station Freedom Program (SSFP), have 
selected Ada, NASA has no agency-level policy about the use of Ada or the train- 
ing, research, or new infrastructure that the use of Ada may require. 

McGarry then presented the ASMAWG’s findings and recommendations. The key 
finding is that Ada is an appropriate vehicle to support the evolution to improved 
software practices in NASA. The ASMAWG also found that the agency’s current 
training programs, Ada experience base, agency-level planning, software stand- 
ards, internal support organizations, software research, and measurement pro- 
grams are inadequate to support a transition to Ada and to the use of the best 
software engineering practices. 

The ASMAWG’s key recommendation is that NASA should adopt Ada as its stand- 
ard programming language for all mission software and should phase in its use 
over a 10-year period. Management of the transition to Ada and to improved 
software engineering should be the responsibility of two new task forces: the Soft- 
ware Engineering and Ada Implementation Task Force (SEATTF) and the Software 
Process Engineering Task Force (SPETF). The agency should also develop agency- 
wide standards for software management, development, acquisition, and assur- 
ance. NASA should also formulate a set of functional capabilities for a standard 
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software development environment and generate these capabilities on common 
support systems. NASA should establish incentive programs to make Ada and 
state-of-the-art software engineering attractive to its contractors. Finally, NASA 
should expand its efforts in Ada and software engineering training, research, and 
measurement. 

In closing, McGarry stated that the working group was not prepared to place a total 
dollar figure on the plan but thought that NASA would have an easier time identi- 
fying required funding than identifying required NASA personnel. He stated that 
adoption of the plan would not decrease NASA’s overall software budget but would 
result in an increase in the functionality and reliability of NASA’s software and a 
decrease in cost for given functionality. He considered the plan to be an integrated 
whole and was not willing to prioritize the recommendations or indicate which ones 
he would be willing to forego in favor of others. 

In response to questions from the attendees, McGarry stated that he presumed that 
funds for training and other agency-wide transition costs would be provided by 
NASA institutional sources rather than from the budgets of individual projects. He 
thought that it might be possible to estimate the costs of carrying out some of the 
particular recommendations, such as that pertaining to standards development, but 
it would take the next detailed level of planning before a more precise cost could 
be determined for the entire set of recommendations. 

Some attendees were concerned about whether enough Ada programmers are be- 
ing trained by the universities. McGarry and Marvin Zelkowitz of the University of 
Maryland stated that they thought general training in computer science and soft- 
ware engineering was more important than language training at the university level 
and that NASA could provide Ada training for graduates with such backgrounds. 
However, McGarry felt that the precise definition of a training program and the 
determination of the numbers of persons who should participate in it are beyond 
the scope of the ASMAWG’s activities. 

McGarry stated that he would like to see headquarters establish a permanent office 
in charge of the agency’s software engineering. The recommended task forces that 
primarily consist of center personnel working part-time or temporarily should be 
seen as stopgap measures. 

McGarry called on Daniel Roy, chair of the Performance Issues Working Group of 
the Special Interest Group on Ada, to answer a question about the efficiency of 
object code generated by today’s Ada compilers. Roy responded that the speed of 
such code is adequate for most applications, excluding those that must run on 
certain microprocessors. He stated that the best optimizing Ada compilers are as 
good in this respect as the best C compilers. He also said that Ada’s concept of 
the program library makes possible an entirely new class of optimizations that are 
not possible, for example, with FORTRAN. 
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INDUSTRY PERSPECTIVE ON RECOMMENDATIONS 

SESSION 2 

McGarry then proceeded to introduce a series of industry representatives. He had 
asked each company to review the ASMAWG’s recommendations and assess their 
impact from the company’s perspective. 

Hughes Aircraft 

Ray Wolverton, Chief Scientist at Hughes Aircraft, introduced the Hughes re- 
sponse. Bruce Krell, Senior Scientist/Engineer, presented the body of the briefing. 

Hughes strongly supports the entire plan, because it recognizes growing contractor 
capabilities and mirrors similar activities in Hughes. Hughes has already used Ada 
on projects with stringent requirements, and feels that the 1998 target date for 
completing the transition to Ada is conservative. 

Krell proceeded to address each recommendation individually. Hughes agrees that 
NASA should evolve to Ada as its standard programming language. Like most 
major NASA contractors, Hughes is making major investments in software technol- 
ogy for Ada and is building an extensive Ada experience base. It is important to 
have a waiver process, however. There is a large legacy of code written in other 
languages, and some things cannot be done well in Ada. Waiver approval author- 
ity must be at an appropriate level. 

Hughes supports the establishment of a Software Engineering and Ada Implemen- 
tation Task Force (SEATTF). A major change requires a sponsor within the organi- 
zation. 

They agree that NASA should develop and adopt tailorable standards for software 
development, management, and assurance. Standards facilitate communication 
between contractors and NASA, and they enhance the repeatability and predictabil- 
ity of the software development process. However, they should be tailorable by 
deletion or addition. 

Hughes agrees with the concept of functional commonality for NASA software 
support environments. However, NASA should recognize that tools are evolving 
rapidly and that the marketplace should be left free to adopt the best tools avail- 
able at a given time. In addition, NASA will benefit if contractors use their own 
existing resources. 

Krell said that Hughes agrees that each center should develop a plan for evolving 
to Ada. Because effective software engineering and Ada must reflect specific 
missions and applications, the plans should reflect the needs of the individual cen- 
ters and their missions. Hughes has taken this approach internally for different 
product lines. 
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They agree with the development of a core curriculum in software engineering and 
Ada. Krell then elaborated on the content and length of the courses in Hughes’ 
core Ada curriculum. 

They agree with the requirement to write and implement a risk management plan 
for critical projects. A risk management plan for Ada projects can help reduce the 
perceived risks of evolving to Ada. They added, via Bryce Bardin, that risk man- 
agement plans should be generated for all projects, not just critical ones. 

Hughes feels that incentives from NASA to use Ada are not necessary for large 
system houses. Incentives could, however, be useful to encourage software reuse 
and to assist smaller companies that are not yet committed to Ada. 

They agree with the recommendation for agency-wide coordination of software 
research and development (R&D) because such coordination will improve the infu- 
sion of Ada technology and accelerate the transition to Ada. 

Hughes supports the establishment of an agency-wide program to collect and use 
software metrics because metrics are necessary to manage the software develop- 
ment process. A phased approach to metric collection should be used, starting 
with a small number of key statistics. 

They support the establishment of a Software Process Engineering Task Force as a 
natural conclusion from previous comments. 

In response to questions, Krell stated that it is not possible to separate the costs or 
benefits of software engineering from Ada: the two must be used together. He 
also said that those who have been exposed to Ada and software engineering tend 
to use them on other projects, not just on mission software. Finally, he said that 
Hughes has had to provide Ada training rather than rely on colleges, which tend to 
ignore data abstraction and tasking. 

IBM 

Judy K. Fleming, Manager of Space Station Software Engineering at IBM in 
Houston, presented IBM’s response. She said that the ASMAWG reports are simi- 
lar to some IBM internal reports. IBM has experienced growing pains and formu- 
lated plans to alleviate them in a similar fashion. For NASA to adopt Ada would 
be a “great idea.” Both IBM and NASA recognize the need to adopt new software 
engineering technologies and tools as much as a new language. 

Fleming asked whether the NASA role is to acquire software or perform Ada de- 
velopment. These roles require different foci in training, standards, and develop- 
ment environments. In either case, she thought that NASA should build on the 
considerable work already done by contractors, academia, and the DoD. 

She said that the selection of Ada for the Space Station Freedom Program (SSFP) 
represents an enormous commitment by NASA. The SSFP provides an 
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opportunity to accelerate the milestones in the ASMAWG 5-year plan and to fulfill 
larger agency objectives. The SSFP’s Software Support Environment (SSE) pro- 
vides leverage as a prototype development environment. NASA should use it, 
learn from it, and focus reuse and measurement activities on it. 

Fleming then made the following specific comments on the recommendations: 

Ada Adoption. NASA should establish a clear strategy for the use of pre-existing 
non-Ada code and commercial off-the-shelf software. NASA should identify a few 
acceptable special-purpose languages such as fourth-generation languages for data- 
base interfaces and nonprocedural languages for artificial intelligence and expert 
systems. NASA should use R&D efforts to facilitate the coexistence of special 
languages with Ada. 

SEAITF. This is a good mechanism to spread lessons learned throughout NASA. 
The SEAITF could serve as NASA’s pipeline to DoD, the Software Engineering 
Institute (SEI), Software Technology for Adaptable and Reliable Systems, and 
similar organizations. IBM would like to participate in the SEAITF. 

Policies and Standards. IBM agrees with the idea of tailorable standards and rec- 
ommends an agency-wide focus on review points (especially “red flags”), measure- 
ments, reuse, and deliverables and their formats. The SSFP is developing its own 
standards and procedures, which could evolve into standards for agency-wide use. 

Software Development Environment. NASA is already developing a prototype envi- 
ronment, the SSE, and is too far along to invest in another prototype. NASA 
should learn from the SSE and influence its evolution, especially with respect to 
metrics, reuse, and the integration of software deliverables. IBM supports the 
specification of functional capabilities but not the development of specific tools on 
specific platforms. IBM recommends defining a framework of interface specifica- 
tions that promote maintainability, portability, and reusability but do not limit con- 
tractors’ use of the latest and greatest tools and methods. 

Training. The recommendation is a reasonable approach. Project-specific training 
will also be needed, and access to a cadre of experts following training would 
enhance on-the-job training. 

Risk Management. A risk management plan is required for SSFP. Ada-specific 
content should be added. 

Contractor Incentives. Ada readiness is an essential consideration in the proposal 
evaluation process. It is probably unnecessary at this late date for NASA to share 
training costs. Incentives should focus on reuse, making it financially rewarding to 
reuse rather than build. NASA should also recognize the life-cycle shifts implicit 
in the use of Ada, proper software engineering practices, reuse, and prototyping. 

Software Measurement Program. NASA should drive the SSE to meet agency-wide 
requirements. The SSE developers already have plans for tool support of the 
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collection of a wide range of software metrics. The Jet Propulsion Laboratory’s 
software cost engineering specialists should also be involved. They have historical 
data and a proven methodology for data collection and analysis. Finally, NASA 
should take advantage of the SEI Measurement Task Force. 

In response to questions, Fleming said that IBM’s transition to Ada was not diffi- 
cult. They were able to modify their existing software engineering courses to apply 
to Ada. Nor did IBM suffer severe internal resistance to Ada once real Ada 
activity began (in the last 3 to 5 years). The economic effects of front-end loading 
the development cycle will not be apparent until IBM has recorded cost data for 
long periods. 

SESSION 3 

Computer Sciences Corporation (CSC) 

Dick Taylor, Assistant to the President of the System Sciences Division, presented 
CSC’s response. CSC’s overall impression is that the report is thoughtful, candid, 
accurate, well done, and a rational basis for beginning. CSC feels that software 
engineering is central to building current and future systems. Future successes are 
increasingly dependent on greater discipline, quality, and productivity. Production 
of new software engineers fails to meet demand. A long-term view is mandatory to 
achieve significant change. The keys to greater quality and productivity are a 
commitment to software engineering principles, standardization without excessive 
constraint, trained and motivated people, measurement, R&D, and software reuse. 

Taylor made the following specific comments on the recommendations: 

Ada Adoption. CSC supports NASA’s adoption of Ada as a standard programming 
language. They agree with the ASMAWG’s focus on standardization and think that 
Ada supports software engineering, fosters personnel growth and retention, and 
promotes reuse. CSC thinks that standardization must be supported with training; 
that the transition requires a long-term view; and that risks, resource needs, and 
schedule impacts must be explicitly treated in acquisitions. 

Training. CSC supports the recognition of both the importance of training and the 
scope of training needed. CSC also supports the formulation of a NASA curricu- 
lum and NASA-wide training. CSC is concerned, though, that NASA may not fully 
recognize the costs involved, the effect of the competitive procurement environ- 
ment, and the role of the NASA curriculum for contractors. 

Research and Development. CSC agrees with the recommendations for NASA-wide 
coordination of R&D, enhancement to greater Ada scope, environment and tool 
definition, metrics definition and use, resolution of Ada problems, and pilot proj- 
ects. However, CSC thinks that tool and process R&D should focus on require- 
ments specification issues and should strive for synergism with other R&D 
programs. 
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NASA Infrastructure. CSC supports the development of common NASA standards, 
agency-level organizations for focus and coordination, and the functional definition 
of an environment. CSC would not like to see NASA adopt overly rigid standards, 
substitute task forces for real infrastructure, or standardize on an overly specific 
environment. Nationwide standards are needed that are common to NASA, DoD, 
and FAA. 

Reuse. CSC agrees that reuse is the key to increased productivity and that it is 
currently in a rudimentary state. 

Metrics. CSC agrees that metrics are essential to process improvement and that 
NASA should define agency-wide standard metrics, starting with the essential 
ones. CSC is concerned with the relation of the recommended NASA program to 
other metric programs; the need for confidentiality of the measures; and the objec- 
tive measurement of quality, reliability’ adaptability, and flexibility. 

Contractor Incentives. CSC agrees that acquisitions should encourage improved 
software engineering. CSC is concerned about ambiguities in requests for propos- 
als, the evaluation of training costs, and productivity expectations during the tran- 
sition to Ada. The contractors’ key incentive is to win contracts, and NASA must 
be clear about the criteria for winning. 

Taylor summarized by saying that the report is a fine baseline for departure and 
identified many key issues. Joint NASA and contractor action is required. The 
program needs to be formalized. Many of the issues involved are broader than 
NASA: DoD, SEI, and the Software Productivity Consortium have addressed many 
of them already. 

McDonnell Douglas Space Systems Company and McDonnell Douglas 
Electronics Systems Company 

Joseph J. McCabe, Manager of Software Integration and Testing at the Space Sta- 
tion Division of McDonnell Douglas Space Systems Company, presented 
McDonnell Douglas’ response. He stated that the recommendations are basically 
good and that the 5-year plan supports the recommendations. However, the 
ASMAWG’s approach may not be the most cost-effective. It requires long-term 
commitment and funding, NASA-wide support, and industry involvement. NASA 
needs to consider becoming more of an acquisition agency and less of a develop- 
ment agency. 

McCabe raised several issues about the report: 

• NASA should leverage resources outside the agency to achieve the re- 
port’s goals. 

• A new software support environment will only work if it is flexible, re- 
sponsive to change, and fully supported. 
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• Training must extend beyond NASA and software groups to include sys- 
tems engineering, product assurance, contracts, and finance groups. 

• Metrics should be collected at large and should not be used as a weapon 
against contractors. 

• Exceptions to the use of Ada should not require a complex waiver proc- 
ess, but justifications should be recorded in a knowledge base. 

The plan would have a number of impacts on McDonnell Douglas. NASA stand- 
ards and policies that differ from those of the DoD would create added expense. 
NASA should instead work with DoD-STD-2167 or its revisions. Creating and 
supporting a software support environment that conforms to a NASA standard 
could add cost and reduce efficiency. Selection of Ada will lower productivity 
during the learning curve. A complex metrics collection task and a risk manage- 
ment plan that is disproportionate to the project will add cost. 

In summary, McCabe said that in general, McDonnell Douglas supports the recom- 
mendations and 5-year plan. Everybody would benefit from a focused effort. An 
integrated NASA/DoD/industry/academia plan is needed, and the task must be 
funded with a commitment from NASA to enforce the results. 

TRW - 

Michael Hollowich, System Engineering Manager for EOSDIS, presented TRW’s 
response on behalf of Hal Hart, who had prepared the briefing but was unable to 
attend. He commended the working group for the work they had done and for 
their commitment to the insertion of Ada. He said that the next step should be a 
cost-benefit analysis to prioritize the recommendations. NASA has a major oppor- 
tunity to profit from, if not join, the ongoing DoD initiatives in research, reuse, 
metrics, process models, standards, program office preparation, product and con- 
tractor assessment, and policy. The resulting commonality would benefit NASA’s 
contractors as well. 

TRW has questions about the recommendation for a common support environ- 
ment: 

• Does it imply a single, specific technical method for each life-cycle activ- 
ity? Does it imply NASA acquisition of tools implementing a chosen set 
of technical methods? 

• Does it require contractors to use a specific government-furnished tool- 
set, or may a contractor’s tools be substituted for government-furnished 
tools? 

• Does the recommended “standard requirements for deliverables” mean 
representations of all artifacts of the development processes and their 
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interrelationships (that is, requirements traced to design, code, tests, and 
so on)? 

• Does it imply portability of tools, either individually or as interacting 
suites? Does it recognize the tradeoffs and complex interactions among 
the following? 

Support for reuse 

Compatibility of technical methods (and data exchange between 
tools) chosen for different life-cycle activities 

Compatible, exchangeable representations of information between 
environments 

Adaptability to different projects’ process models 
Assistance to tool builders versus system builders 
Commercial supportability of the support environment 

SESSION 4 

General Electric Aerospace 

Jeffrey Neufeld, Manager of Advanced Programs, presented General Electric’s 
(GE’s) response, which focused on key NASA objectives that most strongly affect 
contractors. 

Mandating Ada. GE endorses this recommendation for three reasons: stand- 

ardization of languages alone is sufficient rationale; the market drivers for Ada are 
good business reasons to focus on Ada; and the software engineering advantages 
of Ada warrant confidence. GE thinks, however, that the waiver process should 
not be too burdensome. 

Standards. GE endorses this recommendation because the adoption of standards 
focuses industry investments. GE strongly supports placing authority for tailoring 
standards at the NASA project manager level. GE is concerned that the report 
talks of developing NASA standards when DoD-STD-2167A is already established 
and supported by commercial tools. GE is also concerned that tailoring before 
contract award can complicate competitive price comparison and suggests having 
contractors bid to a project-modified baseline. 

Software Development Environments. GE endorses the adoption of a standard for 
NASA in-house work and a functionally common environment for the contractor 
community to facilitate the interoperability of software products on large programs 
and to assess contractor readiness. GE does not think that NASA should develop 
an environment, because the commercial market is developing several. GE thinks 
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that specific tools, methods, and processes employed by contractors are significant 
elements in competitive postures. GE suggests that NASA simply define (1) stand- 
ard formats to allow interoperability of software products and (2) functional capa- 
bilities of environments. 

Contractor Incentives. GE endorses the recommendation. The report correctly fo- 
cuses on the cost barriers of Ada and acknowledges the cost and performance risks 
of new technology. GE strongly concurs that financial incentives for contractor 
adoption of Ada and new software engineering will speed the payback to NASA. 
Consideration of a contractor’s Ada and software engineering experience during 
acquisition will be a positive catalyst for change. GE has concerns on outstanding 
issues on incentives for reuse. Liability and warranty exposure, obligations and 
cost for testing, and data rights are issues that need to be resolved. 

Three-Phase Transition. GE strongly concurs with a phased, integrated plan for the 
transition to Ada and improved software engineering. However, GE is concerned 
that the 10-year timetable will lag the industry and delay payback. GE suggests 
using Ada sooner on less complex and critical production projects. 

Software Measurement Program. GE strongly concurs with a NASA standard 
metrics program and with the use of the SEI assessment method. GE is concerned 
that metrics do have cost, which may become a barrier in competitive situations, 
and that the SEI assessment method is not mature yet. 

Neufeld concluded his remarks by saying that NASA’s focus on software engineer- 
ing improvements is a vital step toward achieving the systems planned for the 
1990s and beyond, that a focused strategy will drive contractor response, and that 
appropriate cost-sharing and award incentives are the best mechanism to get rapid 
payback for the transition. 

Lockheed 

Kent Lennington, Chief Scientist, Software Support Environment, spoke for 
Lockheed. He said that, in general, the SSE project endorses all the recommenda- 
tions and the transition model described in the report. Management and technical 
training are important. SSFP use of the SSE will develop an Ada support environ- 
ment experience base. The SSE can serve as an example for policies and stand- 
ards. The SSE will support the collection of many metrics automatically. 

Lockheed made the following specific comments: 

Centralized Task Forces. It is not clear how contractors or NASA projects can 
participate in these groups. Methods to broaden the input to these groups should 
be considered. Examples are periodic open meetings or workshops, wide dissemi- 
nation of minutes, and solicitation of input on specific issues. 

Policies and Standards. Lockheed and the SSE project support this recom- 
mendation and suggest that such policies and standards take into account 
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DoD-STD-2167A, -2168, and related standards. Industry review of draft standards 
is highly desirable. 

Software Development Environments. The recommendation is a good start, but it is 
not an Ada software support environment. It will not provide the expected benefits 
of an Ada software support environment. 

Training. Training is essential to the success of the overall program. Separate 
training for managers and technologists should be considered. Because thorough 
training is costly but essential, some way must be found to attach incentives to it. 

Software Measurement Program. The SSE project has a requirement to define and 
automate the collection of metrics for software development, reuse, management, 
and the life cycle. These metrics, when implemented, could form the basis of the 
recommended program. Care must be taken to keep the measures objective and 
confidential. They should never be used for awards. 

Boeing Aerospace and Electronics 

Weldon Jackson, Ada Engineering Manager, presented Boeing’s response to each 
of the recommendations. 

Ada Adoption. Boeing is committed to Ada and completely agrees with the recom- 
mendation. 

SEAITF. Boeing was successful with a similar approach. The task force should 
have periodic reviews with the centers, and should involve DoD, industry, and 
academia. 

Policies and Standards. Boeing agrees completely that NASA should develop and 
adopt tailorable standards. Standards provide stability. They should be coordi- 
nated with the DoD standards to take advantage of contractor investments in train- 
ing, internal standards, and environments based on DoD standards. 

Software Support Environments. An environment should support the common soft- 
ware development process. NASA should stress required capabilities and tool 
interfaces rather than specific methods or tools. Specifying specific tools may be 
too expensive. The approach to an environment should be evolutionary. 

Transition Planning. Boeing agrees that each center should develop its own plan for 
evolving to Ada. The SEAITF charter should be approved by each center, and the 
center plans should be adapted from SEAITF policies and standards. NASA 
should promote DoD, industry, and academic involvement. 

Training. Boeing agrees completely. The curriculum should be built around basics 
and should emphasize NASA’s role in acquisition management. The training 
should be available to contractors. 
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Risk Management. Boeing agrees completely. Policies and standards should reduce 
risk. With policies and standards in place, risk management can focus on project- 
specific areas. 

Contractor Incentives. Boeing feels that contractors should follow the NASA man- 
date without special consideration. In source selection, NASA should emphasize 
the contractor’s ability to solve the problem, not the tools it has available. Con- 
tractors should be rewarded for creating and using reusable code. 

Coordination of R&D. Boeing feels that NASA R&D should address Ada in the 
context of NASA applications. The DoD, industry, and academia are carrying on a 
great deal of Ada-related research, which NASA should take into account. 

Software Measurement Program. Boeing sees a universal need to collect metrics. 
Metrics should be collected for both technical performance and performance with 
respect to contracts, costs, and schedules. Boeing’s experience indicates that the 
establishment of a metrics program takes much effort and coordination. NASA 
should coordinate the program with DoD, industry, and academia. 

Software Process Engineering Task Force. Boeing agrees with the idea. The task 
force will need instruction and training. Boeing supports the SEI assessment proc- 
ess. 

Jackson concluded by saying that the recommendations will have minimal impact 
on Boeing. Boeing has implemented internal embedded software standards and a 
software support environment that meet DoD requirements. 
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Ada AND SOFTWARE MANAGEMENT IN NASA 
PANEL/FORUM: POTENTIAL EFFECTS ON NASA 


A series of three panels (Sessions 5 through 7) were held on the second day of the 
symposium/forum, followed by a plenary session in which summaries of the day’s 
discussions were presented. 

SESSION 5 

The first panel of the day was introduced by Frank McGarry. McGarry explained 
that the purpose of the forum was to provide the NASA delegates to the sympo- 
sium with the information they would need to make recommendations to their IRM 
Council representatives. The panelists were to comment on the ASMAWG report, 
focusing on the perspective of their organizations. The session facilitator was then 
to invite the audience to probe the panelists’ remarks by asking questions. 

McGarry emphasized that the goal of the forum was to ensure that delegates from 
the NASA centers and program offices had the opportunity to raise all their con- 
cerns and have their questions answered. 

Jack Garman, Johnson Space Center (JSC) 

Jack Garman began by remarking that the meeting was extraordinary in that the 
agency was looking across all centers and activities. Garman noted that NASA was 
going through a transformation with unending programs such as the Space Trans- 
portation System (STS) and the Space Station Freedom Program (SSFP). Al- 
though SSFP depends on shuttle, and subsequent programs will depend on the 
Space Station, the budget has no such stair-step profile. An observer might con- 
clude that NASA is either going bankrupt or has a strong motivation for greater 
productivity and efficiency. If the latter is the case, one improvement must be to 
lessen autonomy across centers. “If we don’t figure out how to act as a team, ...” 
Garman said, “we’re not going to have a chance at being more efficient and more 
productive.” 

Garman observed that the issue here is the technology of software development 
and management, not Ada. Ada, however, is the keystone. Everyone knows some- 
thing about Ada; even the words Ada and software engineering tend to be used 
interchangeably. 

Whereas in the 1970s no one at NASA headquarters was interested in software 
management and languages, Garman said, a number of headquarters offices now 
want to take charge of the agency’s role in software technology. Because neither 
situation is optimum, JSC will push hard for a focus at headquarters. Garman felt 
the Software Management and Assurance Program (SMAP) and activities from the 
ASMAWG effort should be pulled together and put somewhere else. Without a 
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focus at headquarters, he is convinced that NASA increases its chances of diverg- 
ing from government standards such as DoD-S 1U-2167A. The ranking organiza- 
tion that could provide this focus is Code N’s IRM Office, which should either 
grow into these wider activities or should cleave them off. 

Garman noted that the ASMAWG report gives one the impression that NASA 
writes all its own software, whereas NASA spends far more money acquiring soft- 
ware. NASA must also hand over software from one contractor to another to 
maintain. Consequently, Garman said, a clearer view of the acquisition role of the 
agency should be provided. 

On the topic of incentives, Garman observed that they would be of greater advan- 
tage to smaller companies. Those who do not think incentives are necessary 
should still urge NASA to provide them. “The issue is not whether we need them, 
but whether they will accelerate this technology and help the industry of this coun- 
try, which is one of our roles.” 

Sue McMahon, HQ/OSSA 

Sue McMahon was the representative of the Office of Space Science and Applica- 
tion (OSSA). McMahon provided some background into the “culture” of OSSA 
which, she said, is consciously decentralized. In OSSA, the project manager has 
historically been king. However, in a world of SSF attached payloads and shared 
data analysis, they will no longer be able to work independently. 

There are seven disciplines within OSSA, and these traditionally have had inde- 
pendent spacecraft and instruments. OSSA has 20 percent of the NASA budget, a 
share that McMahon said will probably rise and fall with the SSFP. OSSA is 
currently faced with having to turn off existing spacecraft to build funds for new 
projects. On projects such as the Mars Observer, OSSA is also considering taking 
instruments off the spacecraft so they can afford the costs of operations and data 
analysis. 

McMahon observed that OSSA is risk-driven and, consequently, very conservative. 
Introducing new technology such as Ada is a risk that project managers, who bear 
the responsibility for the success and budget of a project, will not assume voluntar- 
ily. 

McMahon displayed a viewgraph that showed the many launches of OSSA- 
sponsored instruments and spacecraft that are scheduled from 1989 through 1993. 
Recognizing that Space Station payloads and the Earth Observational System are 
starting to drive OSSA into a major culture change, the Associate Administrator 
(AA) for OSSA has initiated a study to determine a strategy and plan for prioritiz- 
ing their needs. Although the ASMAWG recommendations are in budgetary com- 
petition with other equally good ideas, the timing of the report is very good. 

Because of its distinctive culture, McMahon thought that mandates would not work 
now in OSSA. However, a recent report on the needs of OSSA scientists to the 
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year 2000 reads like a rationale for the ASMAWG study, she said. “We can see 
we’re in a world where we must work together much more.” 

McMahon noted that there are several matrix divisions within OSSA whose job it is 
to make the OSSA world better. The job is a difficult one because they must show 
they are adding value to projects but have no independent budget or authority. In 
this light, the ASMAWG recommendations appear too simple: “We can’t expect to 
give the plan to code N and Q and have it ripple through the agency.” More time 
should be spent determining how the plan can be implemented. 

Tom Thornton, Jet Propulsion Laboratory (JPL) 

Tom Thornton prefaced his remarks by saying that he wanted to provide some 
perspective to help the audience understand how JPL will arrive at its conclusions 
on the ASMAWG reports. He is convinced that these conclusions will be to “fully 
support all recommendations and join with Goddard as an advocate of this ap- 
proach to systems engineering.” 

Noting that the recent Magellan launch was JPL’s first planetary launch in 
11 years, Thornton said that one other aspect of this event was also cause for 
excitement: major software systems for Magellan were delivered on schedule, with 
full functionality and within cost. The Magellan software implementation, he said, 
was one of smoothest he has ever seen. 

Five or six years ago, Thornton explained, a large number of software projects at 
JPL were in trouble. A task team was put together to examine the software engi- 
neering process. Their recommendations for standards, a software resource cen- 
ter, training, metrics, tools, and quality assurance (QA) closely paralleled those of 
the ASMAWG. The small pilot projects JPL chose to test the implementation of 
these recommendations have been extremely successful. “This experience will 
help us make a recommendation to follow through with this report,” he added. 

Thornton remarked that he personally believes Ada will soon be the preferred 
language of software engineers, although C is the current language of choice at 
JPL. JPL has had good experiences with Ada in developing the Global Decision 
Support System, of which 270 to 400 thousand lines of code (LOC) are in Ada: 
the cost of the project did not increase; it was easy to put in the field; and was 
virtually error-free. Other JPL projects under development will be implemented in 
Ada, and Ada training courses are progressing extremely well. “This background 
leads us to conclude that Ada is a good mechanism to help with software engineer- 
ing methodology,” he said. 

Expressing concern with costs, Thornton said JPL needed some idea how much the 
plan would initially cost to implement. Because project managers have to accept 
the plan, they need to understand the effects on their costs as well. 

Thornton also noted that flight project managers will want to know if Ada will 
improve productivity. He then described another Ada project that uses 
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DoD-STD-2 1 67A, independent testing, and the methods of a good software engi- 
neering environment. This project’s productivity is an order of magnitude lower 
than the JPL norm (2 LOC versus 20 LOC per day). 

Thornton also voiced the concern that JPL would not want to use Ada for artificial 
intelligence and simulations. NASA needs to worry about how other languages are 
integrated into Ada programs, he said. 

On the topic of incentives, Thornton noted that one can go from 10 LOC to 
20 LOC per day by doing smart things, but you cannot go to 100 LOC per day 
without reuse. He would vote to change the incentive recommendation to focus it 
on reuse. “When you do that, you are focusing on productivity and are giving the 
incentive to project managers to want to follow in this direction.” 

Rob Kudlinski, Langley Research Center (LaRC) 

Rob Kudlinski began by saying that several groups of Langley managers had re- 
viewed the ASMAWG reports and that the recommendations were very well re- 
ceived. The key point of their response was that they wanted all the 
recommendations implemented as a package. Managers at Langley are concerned 
about the risks of infusing a new technology into a project. It would not do, they 
felt, to adopt Ada and fail to go through with the funding, training programs, or 
task force. 

The timing of the report is excellent from Langley’s perspective, Kudlinski noted, 
because they currently have a group that is assessing the flight software develop- 
ment process. Flight software projects have traditionally been small at Langley 
and often consist of pieces that remain after the project’s hardware is engineered. 
With software projects now growing larger and more complex, LaRC needs a cen- 
tral focus for software engineering. 

The recommendations of the assessment group at Langley, Kudlinski said, are 
similar to those of the ASMAWG. These include adopting Ada, standards, risk 
management plans, and metrics. Langley has started two pilot projects in Ada: 
one is a parallel development of a PL/M project; the other will use Ada for a long- 
term project that is expected to go through considerable evolution. 

Kudlinski asserted that the idea of a task force was essential. The central facility 
would prevent the centers from duplicating the effort needed to investigate method- 
ologies, set up standards and policies, and obtain information. 

Langley is currently using SMAP’s Information Systems Life-Cycle and Documentation 
Standards, Version 4.3, and is setting up a metrics program. Project managers 
recognize that they need help. They welcome assessment and have readily ac- 
cepted standards. 

Training, Kudjinski observed, is critical for Langley because few managers or pro- 
grammers know Ada. Although his group is trying to establish a training program, 
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they have had difficulties with funding. In consequence, they believe an agency- 
wide program that is fully funded from the agency level would be a key element. 

Kudlinski suggested that the training program include a certification program for 
contractors. He noted that agency-sponsored contractor training would constitute a 
good incentive, as would higher proposal scores given for contractor facilities and 
systems that support good software engineering practices. 

In conclusion, Kudlinski stated that Langley supports all the ASMAWG recommen- 
dations and that his memo to the IRM Council will reflect this support. He ex- 
pressed a desire to see some recommendations from the SEAITF as soon as 
possible, so that the tools that Langley is purchasing could be selected to fit into 
the common support environment and so that Langley’s training courses could be 
made compatible with an agency-wide curriculum. 

Discussion 

The first issue addressed in the discussion period that followed the panel presenta- 
tions was raised by Ed Seidewitz (GSFC). Seidewitz noted that although contrac- 
tors wanted to go ahead with the recommendations, NASA seemed to be saying, 
“These sound like good ideas if you can get the project managers to accept them.” 
If the recommendations were good for NASA as a whole, was it time for upper 
management to take some of the prerogative away from project managers? 

v Tom Thornton replied that this would not work and such an attempt would stop the 
plan cold. “What you’ve got to do,” he said, “is to convince a few of the project 
managers there is a great benefit here. If you convince them that their job will 
1) be easier and 2) be less expensive and entail less risk, then they will join forces 
with us.” 

Sue McMahon noted that a project manager must fight each year for money, and 
that these battles hurt planning for the use of a tool like Ada or a software engi- 
neering methodology that needs front-loaded funding. We have to help the project 
managers, she said, by providing them with the information that makes it easy for 
them to agree to the plan in view of the tough budgetary tradeoffs they have to 
make. 

Jack Garman observed that JSC project managers are driven by the need to retain 
visibility into software projects and to manage risks, and that there is a growing 
hue and cry for synergism from the line organizations to support them. He thinks 
the world might be ready for a bit of “thou shalt” because it would relieve the 
project managers of some responsibility. 

On the issue of costs to project managers, Frank McGarry remarked that there is a 
10-year period in which we have to understand the implications of Ada before 
project managers would be told to use the language and given the reasons why. “I 
don’t think right up front, ...” McGarry said, “we are looking to impact projects 
universally or at all.” 


5443 


25 


Members of the audience commented that a new technology needs advocates who 
are practitioners, and that one way to attain good grass roots support for Ada is to 
institute a good training program because most programmers and managers will 
gravitate to Ada technology. 

Asked whether the training recommended in the report would result in extra ex- 
pense or whether it could result in savings if the centers pooled their existing 
educational funds, McGarry replied that, although it would be good to be able to 
say there would be no additional expense, at this time they just did not know. 

In response to a comment by Marvin Zelkowitz, McGarry said he hoped NASA 
would act on the ASMAWG’s recommendations; at the very least, the agency 
should take a position on the report. Jack Garman concurred, noting that NASA 
has no choice but to take action and become more efficient. 

Asked how JPL enforces standards, Tom Thornton said a JPL team worked for 
2 years to obtain consensus on the standards. They were then signed by the Direc- 
tor and put into place. The QA group, said Thornton, should not enforce stand- 
ards because such actions cause conflicts. QA has an audit function; it is the line 
organization that enforces the use of the standards. Sue McMahon added that 
many previous committees at JPL had also advocated standards. It took a different 
JPL director to create the atmosphere in which consensus could be attained. 

McGarry expressed the opinion that it was implausible to expect individual projects 
looking at their own worlds to come to the same conclusions about standards and 
Ada. Advocates who are looking at the global picture are needed. Then upper 
management must exert some pressure. Jack Garman said that one clever part of 
the recommendations was to require that each center do its own transition plan 
because this was a way of getting consensus. At the least, it would cause the 
administrators to ask where the standards were. 

Eileen Quann commented that a distinction should be made between standards and 
guidelines. Standards tend to be overly specific and have to be scoped down by 
small projects, whereas guidelines are usually accepted by project managers and 
can be scoped up. Gary Raines said that because a project office buys systems, 
not software, standards for software and hardware must be compatible. 

McGarry then asked the panel, “Should we have NASA-wide software standards?” 
Sue McMahon answered in the affirmative, adding that the SMAP standards 
should form the prototype version. Tom Thornton also responded with a qualified 
“Yes,” noting that before the establishment of lab-wide standards, each JPL office 
had developed its own, thus inefficiently reinventing the wheel. Jack Garman said, 
“Yes, of course, it [having standards] is a form of corporate memory.” 
Rob Kudlinski also said “Yes,” then drew laughter by observing that “At Langley, 
we have carefully positioned ourselves for this by not using any standards over the 
years.” 
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SESSION 6 

Ed Seidewitz of GSFC introduced the members of the second panel. 

John Dalton, GSFC 

In his introduction, John Dalton stated that he would attempt to summarize com- 
ments from both Mission Operations and Data Systems Directorate personnel as 
well as from his own Data Systems Technology Division. 

The real issue is effective software engineering and management, said Dalton. 
Although many of those for whom he spoke support Ada, some are concerned that 
mandating Ada would result in over-zealous enforcement of its use. The training 
program for software practitioners and acquisition managers is the key to achiev- 
ing a middle ground, so that standards are neither ignored nor applied in inappro- 
priate situations. 

Dalton would stop short of recommending Ada as a standard. Ada should be 
adopted as the language of choice, realizing that it is not suited to some projects. 

The answer is to provide an infrastructure rather than a policy solution, said 
Dalton. A task force is insufficient. An agency-wide organization such as JPL’s 
Systems, Software, and Operations Research Center (SSORCE) or the Software 
Engineering Laboratory (SEL) is needed to support software engineers and to pro- 
vide tools and methodologies. 

Concerning the common support environment, Dalton recommended that the 
agency concentrate its energies on methodology and tools, and on the interfaces 
among those tools. He recommended that industry be encouraged “to focus. ..on 
meeting those interfaces, so that we have an environment that can grow as we get 
smarter.” 

Debbie Hahn, Kennedy Space Flight Center (KSC) 

KSC has a perspective different from that represented by previous speakers, said 
Debbie Hahn. KSC is oriented toward mission goals rather than projects. Its 
mission experience has taught the center many lessons about reusability, maintain- 
ability, standards, and interfaces. 

Hahn noted that designing systems to last for 30 and 40 years is new to KSC, and 
that the answer to doing this successfully lies in standard interfaces and standard 
software technology. KSC is interested in system standards because they want 
their systems to work. They are closely involved in the SSFP and have adopted 
SMAP and the Software Support Environment (SSE) toolset. 

Although KSC agrees that software standards are needed, said Hahn, center per- 
sonnel do not want NASA to reinvent the wheel. Most companies have been 
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required to propose software and system standards and design methodologies, and 
they have these in place. Industry standards, the SMAP standards, and Air Force 
standards could be used and refined. What NASA needs is grassroots participation 
to provide input and to ensure cooperation from the centers. It is also essential 
that standards be applicable to both large and small payloads and projects. 

Hahn noted that KSC is strongly oriented toward C. They have had to build a 
generic checkout system on a Unix platform, and have found C to be very powerful 
and easy to learn. Although KSC will use Ada for the test, control, and monitor 
system for the SSFP, there is a lot of resistance to Ada at the center. Training is 
needed if the line managers are to overcome their prejudices against Ada. 

Hahn felt that the SSE’s goal of providing a software environment for everyone 
working on SSFP software is too broad. It has been difficult to get the project 
managers to limit the scope of the SSE so that the project is manageable. 

In summary, Hahn said that KSC agrees with most of the ASMAWG recommenda- 
tions, i.e., standards, metrics, etc. She suggested that there will be less resistance 
to these if Ada is “put away in parentheses.” 

AI Kopp, Telesoft (formerly of DoD) 

A1 Kopp opened with the explanation that he would be speaking from three differ- 
ent perspectives: as an Ada proponent, as a retired DoD employee (Ada Joint 
Program Office), and as a Telesoft spokesman. To help the audience, he had a 
different hat for each of these parts of his presentation. 

Donning his DoD hat, Kopp noted that when the DoD was examining existing 
languages, they considered the same factors as the ASMAWG: e.g., the increasing 
complexity of software requirements, the larger percentage of systems costs attrib- 
utable to software, and the shortage of software personnel. The DoD decided it 
needed a single language designed to meet all of its requirements. Kopp displayed 
charts showing the recent migration from other high-order languages to Ada. 
Fourth-generation languages are compatible with Ada, he added, and in the future 
they may be built in Ada. 

Kopp observed that the DoD policy on Ada usage had evolved over the years. Ada 
was originally to be used for embedded systems. When Congress defined 
“mission-critical,” it opened the scope for Ada in DoD. Under Secretary 
Richard DeLauer’s memorandum of 1983 was a result; it designated Ada as the 
primary language for “mission-critical” computer resources, i.e., those used for 
cryptologic and intelligence activities, weapons, and command and control. The 
real surprise came in 1985 when the Army mandated Ada for information systems. 
Kopp felt that NASA might well do the same because Ada is well suited to infor- 
mation management systems. 

Kopp stated that the technical issues DoD had to face because of the immaturity of 
the language no longer inhibit Ada’s use. Compilers now exist that generate code 
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that performs well at runtime. NASA will still have to address other issues associ- 
ated with the change to Ada, but these are manageable. 

It is true, Kopp said, that Congress did not mandate Ada for the DoD. However, 
Ada is an important political issue because of its potential for improving perform- 
ance and productivity. He expects Congress to continue to be involved with Ada 
through the appropriations process. In DoD appropriation bills, Congress has re- 
quired the DoD to accelerate the introduction of Ada and has recently ordered it to 
evaluate as well as validate Ada compilers. We can expect Congress to monitor 
Ada technology in NASA as well, Kopp added. 

Switching to his Telesoft hat, Kopp said that NASA would be moving into a strong 
technological base in adopting Ada. Because software accounts for 5 percent of 
the gross national product, Ada also has a large commercial potential. Kopp dis- 
played several charts from the Ada Information Clearinghouse that showed Ada’s 
growth in the academic and commercial sectors. Ada has already been successful 
in technology houses such as Telesoft, he said. The advantages of Ada in reuse 
are being seen in the rehosting and retargeting of compilers. 

Kopp displayed graphs published in the Journal of Electronic Defense that showed 
that the productivity on an avionics electronics project rose over a set of builds, so 
that the productivity by the end of the project was higher than that associated with 
typical high-order languages. Telesoft also has a European partner that is intro- 
ducing Ada over a range of applications. This organization has found that Ada is 
providing a faster return on their investment than they had expected. These exam- 
ples show that Ada is profitable in either the short or long term, Kopp concluded. 
However, because its introduction requires a learning period and investment, help 
is needed in advancing Ada technology. “This is the most valuable addition that 
NASA’s joining the Ada community can provide,” he said. 

Tony Carro, NASA Headquarters/Office of Space Operations (OSO) 

In his opening remarks, Tony Carro commented that the ASMAWG recommenda- 
tions are comprehensive and well thought out. Adopting Ada is probably a good 
move, he said. 

Carro asked why the working group had restricted itself to mission software. Most 
Code T systems relate to ground systems, and it is unclear which would be con- 
sidered mission software. Code T has already chosen Ada for some major proj- 
ects, he noted. 

Carro had several disagreements with the plan. He felt the proposed time for the 
transition to Ada is far too long. In addition, a fairly accurate idea of the costs of 
the plan is needed; training and other transition costs might be considerable and, 
therefore, would act as a strong deterrent. 

“We’re not separating the issue of standards, the issue of software engineering, 
and the issue of Ada,” Carro objected, saying that these should be dealt with 
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individually. He was also concerned with large projects for which a language 
decision was needed immediately. Should we recommend Ada, or are there other 
options? Is it sufficient to use good software engineering principles? Carro also 
noted that NASA had already decided to use Ada on some large projects and asked 
if this might obviate case-by-case decisions on other similar projects. 

Personally, said Carro, he believes Ada is a good compromise as a standard lan- 
guage if the appropriate waivers are granted. However, the ASMAWG made 
points that are not applicable only to Ada, e.g., “Ada encourages the use of soft- 
ware engineering, encourages reusability, and lowers the life-cycle cost.” Most 
contractors are already using software engineering principles whether or not they 
use Ada, he remarked. Neither is reusability an exclusive property of Ada. Ada 
does not enforce reusability, which has to be designed into the system. 

On the question of costs, Carro observed that “no one is giving any numbers.” If 
the agency is going to make this major switch, it must have a precise idea of the 
expense. The costs of training and tools are large enough that the savings with 
Ada will only be realized in the future. Therefore, NASA must ensure that costs 
will be lower over the life of a project. 

Discussion 

Panel facilitator Ed Seidewitz responded to a comment from the audience that 
Modula and C++ as well as Ada promote productivity gains, software reuse, and 
engineering principles. He noted that because NASA’s new projects will have 
lifetimes of 20 or 30 years, the agency must build software that is more reliable 
and maintainable. It is natural to choose a standard language, he said, and Ada is 
a reasonable choice. The argument is not based on the technical merits of Ada 
versus Modula, C, or C++ but on the DoD, contractor, and vendor support that 
Ada enjoys. Tony Carro voiced his agreement with this statement. 

Seidewitz then asked the panel if NASA should choose a standard language at all. 
Debbie Hahn answered “No,” noting that, for KSC’s real-time control and check- 
out systems, Ada is more of a hindrance than a help. Hahn said she believed KSC 
would gain more by specifying software engineering principles. 

A1 Kopp said that the DoD wanted high reliability and long-term maintainability, 
for which Ada is the best choice. Because NASA is dealing with the same prob- 
lems, he would answer “Yes” to the question. 

John Dalton gave a modified “No.” NASA should have the goal of using a com- 
mon language and should remove barriers to achieving this by providing Ada 
training and other support. However, adopting a standard language would result in 
rote decisions. Unless managers understand how to make language decisions cor- 
rectly, and unless the waiver authority is delegated to a low enough engineering 
level so as not to impede productivity, “we would be shooting ourselves in the foot 
for the sake of a standard language.” 
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Tony Carro answered that he felt the agency needs commonality. If it continues on 
its current course, NASA will have the same problem with multiplicity of lan- 
guages as did DoD, and reuse will suffer. . Carro said he thinks Ada is a good 
choice. He believes in standards as long as there can be waivers. 

Jack Garman asked whether one would be using Ada if he were using a tool, such 
as a data base management system (DBMS) or fourth-generation language (4GL), 
which was implemented in Ada. Members of the audience replied in the negative, 
noting that a FORTRAN compiler could be written in Ada. John Dalton said that 
this question might illustrate the need for latitude in the language policy because 
people who did not understand the essence of the problem might answer the ques- 
tion differently. DoD’s answer to the question would be “No,” said Kopp. He 
noted that the SEI recommends keeping Ada and Structured Query Language 
(SQL) distinct, so that both languages remain intact and the interface between 
them is clean. 

One attendee commented that he interpreted the report as saying that Ada would 
be the standard procedural language replacing FORTRAN and COBOL, but it 
would not be the language for special purposes such as rapid prototyping. 
Seidewitz agreed that there is a lot of latitude in the recommendations. He noted 
that the report does not suggest the use of Ada for research, management informa- 
tion systems, or new technology. It does not preclude the use of C++; it mentions 
the use of DBMSs and 4GLs; and it describes a nonburdensome waiver process. 

Jeff Neufeld noted that industry pushes for a standard because it costs more to 
support four languages than one and that standardization always involves a com- 
promise among capabilities. Bruce Krell expressed the opinion that commercial 
software vendors are going to adopt Ada to achieve reusability. 

One member of the ASMAWG sitting in the audience noted that the working group 
had engaged in many of the same debates. The NASA mandate for research, he 
asserted, precludes the use of Ada alone. However, NASA’s mandate for long- 
term missions requires the agency to use a language such as Ada because of its 
support for maintenance. 

An audience member commented that if 4000 rather than 400 NASA personnel 
knew Ada, some of the fear of Ada as a standard might disappear. Another noted 
that his company had no difficulty with the mandate for Ada during its work on the 
Space Station and that the use of modeling tools instead of Ada where these were 
appropriate had not been questioned. 

Joe McCabe reiterated that the waiver authority must be put at the project level. In 
the DoD, Kopp responded, “we equate program managers next to God, and they 
equate themselves as over God.” “If God establishes the standards, then the pro- 
gram managers who are over God make the waivers,” McCabe rejoined. 
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SESSION 7 


Victor Basili of the University of Maryland introduced the last panel. Basili said he 
felt the report was extremely impressive and contained an iterative flavor that 
reflected the scientific process. He was excited that the proposed standards were 
tailorable at the project level and that they could evolve with experience. He 
suggested that a hierarchy of standards be developed, and that NASA provide 
examples of standards tailored for smaller projects. 

Paul Smith, HQ/Office of Aeronautics and Space Technology (OAST) 

Paul Smith stated that OAST agrees with all the findings of the ASMAWG, but he 
recommended that software engineering methodologies be considered separately 
from Ada as a language. Ada can serve important functions agencywide, both in 
methodologies and tools. Although the agency should seek environments that sup- 
port Ada, these environments should be able to accommodate other languages. 

Smith explained that OAST focuses on the basic research that supports the engi- 
neering of highly reliable and complex software systems. The objective of its 
NASA Initiative in Software Engineering (NISE) program is to develop the tech- 
nologies, methods, and skills that will facilitate cost-effective development and 
management of reliable software that is maintainable for long periods of time. 

The agency should provide incentives for software reuse, Smith said. Training is 
also needed to establish a knowledge base. He commented that some of NASA’s 
requirements may not demand implementation in Ada specifically. 

Smith felt that the following perceptions of Ada within the agency needed to be 
addressed: 

• Ada compilers have had deficiencies. 

• Ada is not the desired solution for real-time spaceflight applications, be- 
cause they employ small onboard memories and require high execution 
speeds. 

• Ada is not efficient for multiprocessor applications. 

• Ada does not support fault-tolerant features well. 

• Ada is not well received for modeling. 

• C is the up-and-coming language in universities. 

Smith then made several observations: NASA must employ state-of the-art soft- 
ware engineering practices; the agency must understand the financial impacts of 
the recommendations over its many diverse applications; the definition of mission 
software needs examination; and NASA needs to address the integration of other 
programming languages into the structure recommended by the ASMAWG. 
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Smith expressed doubt that universities will provide enough students trained in 
Ada. He stated that the agency should examine DoD’s long-term projection of 
Ada’s impact. He also asked 

• Is Ada used in the commercial environment? If not, what is used and 
why? 

• Concerning the 10-year phase-in, how long would it take for a large proj- 
ect to go through enough of the life cycle to demonstrate success and to 
provide an experience base? 

• How are increased costs to be supported by projects or NASA organiza- 
tions? 

In closing, Smith commented that the assignments of NASA codes in the 5-year 
plan need to be reviewed and perhaps revised. 

Dave Aichele, Marshall Space Flight Center (MSFC) 

Dave Aichele observed that the ASMAWG had done “a fine, courageous job on a 
difficult problem.” He then expressed a number of concerns. 

The agency’s target should be state-of-the-art software engineering practices rather 
than Ada, Aichele said. 

Aichele took exception to the use of the word all in the report. He also expressed 
concern with the inclusion of modeling in the definition of mission software. 

Aichele felt that NASA Management Instruction (NMI) 2410.6, if applied properly 
through a software management plan and verified by peer review, provides the 
agency with a sizable “leg up on where we’re going to go.” He would have voted 
“No” on agency wide standards, he said. His experience with avionics hardware 
standards makes him believe that standards tend to produce stagnation. 

Aichele expressed the opinion that the agency needs to reestablish the systems 
engineering office at NASA headquarters. This, he said, is where the activities 
recommended in the report should be housed. He felt that little would result from 
a fragmented approach, i.e., assigning activities to various AAs. 

The agency should have a policy that requires centers to use good, state-of-the-art, 
software engineering techniques tailored to the project, Aichele said. To provide 
some leverage from above, the policy should say that the project must consult with 
the software engineering office before issuing a procurement request. 

In conclusion, Aichele said that when NMI 2410.6 was proposed, the response at 
Marshall was, “Why... do I need that for software? I don’t have that for any other 
discipline.” Aichele said he does not see much change in this attitude at the 
centers. Consequently, he expects management to have some objections to the 
recommendations . 
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Kathy Schubert, Lewis Research Center 


One concern that was voiced at Lewis, Kathy Schubert said, is with the scope of 
“mission software.” A clearer explanation of what is or is not included under this 
term is needed. 

Personnel at Lewis feel that for small, self-contained projects, Ada may not be the 
best choice, Schubert said. Personally, she would wholeheartedly endorse the se- 
lection of Ada, but the term mandate creates resistance. 

Another concern is with the costs of the program. Lewis needs an indication of 
what these costs are, both up front and over the long term, and of how they are 
going to be met. 

In summary, Schubert said that her main concern is that the momentum from the 
meeting be carried forward into action. She said she hoped the plan would not 
languish because of inadequate support or funding. 

Discussion 

Vic Basili noted that yesterday industry had said, “Yes, let’s go with the recom- 
mendations,” whereas today he had heard a very conservative view from NASA. 
He asked the panel why there was such a difference in attitude? 

Paul Smith answered that perhaps it was due to the use of the word all in some of 
the recommendations. NASA is a diverse agency, he said. It is working on large 
projects that can certainly benefit from the recommendations, medium projects 
that can benefit by some of them, and small projects that need some flexibility. 
Perhaps, he suggested, NASA does not want to get locked into situations that might 
inhibit innovation. 

Kathy Schubert responded that some of the diversity might be due to lack of expe- 
rience with Ada and could only be overcome by education and training. 

Aichele reiterated his concern with the word all. He also felt that, as a buyer with 
the responsibility of making the project successful, NASA would naturally be more 
conservative than industry. One attendee noted that the industry representatives 
also worked on DoD contracts, and thus were already on the Ada bandwagon. 
NASA knows its own business but lacks this Ada exposure. 

Dan Roy commented on the linguistic aspect of the discussion. “The lingua franca 
of science is English,” he said. Although he finds it difficult to convince French 
colleagues to write articles in a foreign language because they have centuries of 
papers in French that they would like to reuse, it is the communication itself that is 
most important. He would not like the President of the United States to mandate 
English in France, but if the price of communication is to use a common language, 
we should welcome it. 
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Roy said that he was puzzled by the separation of state-of-the-art software engi- 
neering from Ada. “Can you tell me,” he asked, “what kind of software engineer- 
ing you can do without exception handling, without strong typing, without tasking 
and concurrency, without the concept of packages?” If you talk about software 
engineering, you have to consider software engineering with Ada, he said, because 
you cannot succeed “if you don’t have support for limited private types, abstract 
data types, the concept of object-oriented design, and everything that we have dis- 
covered in the 15 years since C was invented to fit in the 16-bit address space of a 
PDP-11.” 

A1 Kopp commented that the industry response yesterday was not at all like that of 
5 or 7 years ago. To have major contractors support language standardization was 
a situation that NASA was enjoying uniquely and one that he wished DoD had had. 
A representative from industry observed that the Ada mandate applies to produc- 
tion software rather than for laboratory development, and that the language is very 
appropriate for this. 

Ray Wolverton responded to an earlier suggestion that perhaps the contractors had 
said what they thought NASA wanted to hear. He said that this was untrue and 
that they had wrestled long and hard with each of the recommendations. They felt 
the coalescence of industry in support of the plan was a plum being handed to 
NASA on a silver platter. 

Ed Seidewitz said that he interpreted NASA’s conservatism as stemming from the 
worry that, on any particular project, standards will inhibit adaptation to new situ- 
ations. On the other hand, the contractors who were actually going to put their 
business on the line by performing the work agreed that Ada should be NASA’s 
standard language. 

Basili said that it is very important to recognize that software is a part of systems 
engineering. He said that NASA is in the software business and that “when you 
talk about systems engineering and it’s not software oriented, I can’t even guess 
what you are talking about.” 

Ed Chevers of JSC responded that NASA has a problem with the universities. 
Although DoD mandated Ada years ago, fewer than 200 universities are teaching 
Ada, and of these fewer than 6 provide degrees in software engineering. Basili said 
that these comments were well taken and that universities were not yet preparing 
students to work in Ada. Universities, he said, are very conservative and short of 
the funds required to purchase the equipment and facilities that are needed. The 
University of Maryland has a good program in software engineering, but there are 
few professors in the field, and it is difficult to find a production environment on 
which to perform research. 

In response to Paul Smith’s question about the length of time needed to provide an 
experience base with Ada, Basili noted that NASA should be closely watching such 
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Ada programs as the $4 billion Advanced Automation System. Dave Aichele said 
that, after 3 years, Marshall had recently completed its first Ada system. This 
project, during which Marshall was a beta test site for the compiler in use, took 
30 percent longer in design, and 300 percent longer in implementation and testing 
than the norm. To an attendee’s comment that this was a bad example, Basili 
observed that it was important to expose such situations and analyze them. 

One attendee remarked that if NASA were to standardize on Ada, it would need 
input to the Ada Joint Program Office so that the changes to the language required 
by the agency could be addressed. As a final comment, another member of the 
audience observed that a risk reduction plan was needed for all software develop- 
ment projects, both large and small. 

PLENARY SESSION- SUMMARY 

Frank McGarry introduced the plenary session with a brief summary of the forum. 
He noted that the first panel had addressed standards in general; the second had 
addressed Ada issues; and in the third session “we picked on universities” and 
discussed the contrasting perspectives of industry and NASA. McGarry then asked 
Jack Garman for his summary observations. 

Jack Garman, JSC 

Jack Garman suggested that the representatives exchange the comments submitted 
to Code N among themselves. The secretary to the IRM council, Don Adreotta, 
agreed with this proposal. 

Garman said that although the agency has not had to act as a corporation previ- 
ously, there are now many reasons for teamwork. The conservatism of NASA 
versus that of its contractors may be due in part to the tradition of autonomy in the 
agency. “Having to give a little to be part of a whole is the toughest thing any 
organization like NASA has to deal with. Any corporation that has been through 
mergers... has the same kind of problem.” 

John Dalton, GSFC 

John Dalton said he disagreed somewhat with Garman about the reasons for 
NASA’s conservatism. Dalton said that the comments he had received were “valid 
technical reservations in certain areas.” People did not dispute the proposal that 
Ada should be the language for most of our projects in the future. It is critical, 
though, that NASA not overreact “as a corporation” in achieving this goal. 

The panel was divided on this issue, Dalton said. Those supporting the standard 
say that if we do not adopt Ada as the standard language, the diversity we have 
today will continue. However, Dalton said, there is a middle ground between 
having no standard and complete diversity. Proponents also make the point that 


5443 


36 


the waiver process will deal with exceptions; Dalton said this would be true when 
and if the waiver process was understood. 

A1 Kopp gave impressive reasons for going to Ada, Dalton added, and he agrees 
that “Ada is the way to go.” Rather than arguing about standard languages, he 
suggested NASA set a goal to train all programmers and managers in agency and 
contractor teams, starting with those doing mission support software. “If that 
works, and the programmers love it, we’ll have achieved our goal.” 

Paul Smith, HQ/OAST 

Paul Smith said it is clear that NASA must take action to improve its software 
engineering practices. He also felt the transition would require the 10 years speci- 
fied in the ASMAWG plan; he did not see evidence that the agency could change 
much faster. 

Smith recommended the agency find ways to improve software reuse. He noted 
that the ASMAWG recommendations need to be considered in light of budgets, 
organizations, phasing, and applicability to all projects. He also felt that the suc- 
cess of the recommendations was greatly dependent on solid and realistic imple- 
mentation plans. Smith said he did not want to leave the impression he was 
against Ada, but the agency must understand the costs and risks. 

Vic Basili, University of Maryland 

Vic Basili observed that the question “Is it Ada or is it good software engineering 
practice?” had been raised throughout the forum. He answered that it was really 
the latter but that Ada supports that good practice. 

The report, Basili said, accepts the fact that software engineering is an experimen- 
tal science and must be studied. If NASA studies software correctly, it will pro- 
duce good software engineering, an evaluation of software technologies, and good 
experience. 

Frank McGarry 

In closing, Frank McGarry said that he was impressed with the contractors who 
had volunteered their positions and recommendations to NASA. Industry and the 
ASMAWG had done their jobs, and NASA had expressed its opinion. The ball 
was back in the court of upper level management, center directors, and the IRM 
Council; it would be disappointing if they drop it. 

Thanking the audience for their attendance, McGarry adjourned the meeting. 


37 


5443 








SYMPOSIUM PRESENTATION MATERIAL 


This section consists of the presentation material from the first day (symposium) 
of the Ada and Software Management in NASA Symposium/Forum. Materials are 
placed in the order of presentation on the agenda. 
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’REPORT OF THE DEFENSE SCIENCE BOARD TASK FORCE ON 
MILITARY SOFTWARE' 9/87 - F. BROOKS (CHAIR) 
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• NO SPECIFIC AGENCY-WIDE POLICIES/PLANS DEFINED 


IMPORTANT QUESTIONS 
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SHUTTLE 

JPL HISTORICAL DATA 
GSFC (SEL) 

UNIVERSITY/INDUSTRY EXPERIENCES 
SEI DATA 


FINDING 1 
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FINDING 3 
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• SSF EARLY Ada COMMITMENT GOOD BUT... 
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AVERAGE 1ST Ada 2ND Ada 3RD Ada 
FORTRAN 
(SAME ENVIRONMENT) 

SOURCE: GSFC (SOFTWARE ENGINEERING LABORATORY) 
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PLANS - GOOD FIRST STEP 
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METHODS, PRACTICES 
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- RAPID GROWTH IN DEMAND FOR S/W (10-20% NASA BUDGET) 

- DYNAMICS OF SOFTWARE ENGINEERING TECHNOLOGY 

- RELATIVE “YOUTH” OF SOFTWARE ENGINEERING 
(VERY FEW UNDERLYING PRINCIPLES (SO FAR) 
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ADOPT Ada FOR ALL MISSION SOFTWARE 
RESPONSIBILITY - CODE NT 
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RECOMMENDATIONS 

DEVELOP PLANS FOR EVOLVING TO Ada 



ASMAWG-25 


IMPLEMENTATION TASK FORCE" (REC#3) 


RECOMMENDATIONS 

ESTABLISH SOFTWARE ENGINEERING AND Ada 
IMPLEMENTATION TASK FORCE (SEAITF) 
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• COLLECT AND TRACK SOFTWARE METRICS 

• STAFFED WITH CENTER EXPERTS (ROTATING) 
- MANAGED BY HQ OFFICE 
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ASSESSMENT REPORTS GO TO SUBJECT ORGANIZATION 
FOR ACTION 


RECOMMENDATIONS 

DEVELOP SOFTWARE STANDARDS 
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• EVOLVE TOWARD COMMONALITY (ELIMINATE MULTIPLE TRAINING 
ENVIRONMENTS, PROCUREMENT PROCESS...) 


RECOMMENDATIONS 
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RECOMMENDATIONS 
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SOFTWARE ENVIRONMENTS 
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• OTHER EXCELLENT MODELS EXIST (E.G. JPL 
FOR MANAGEMENT, TRW FOR Ada/S.E.) 
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• PROPOSAL SCORING CONSIDERATION: 

- SIMILAR TO SEI PROCESS ASSESSMENT 

- USE OF DEMONSTRATION PROBLEMS 


RECOMMENDATIONS 

ESTABLISH SOFTWARE METRICS PROGRAM 
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• SMALL IMPACT TO “MISSION" SOFTWARE PROJECTS 


NASA HAS BEEN EXTREMELY SUCCESSFUL IN SOFTWARE ARENA: 
- CONTINUALLY ON LEADING EDGE OF SOFTWARE TECHNOLOGY 
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NASA SHOULD IMPLEMENT SIGNIFICANT CHANGES TO SOFTWARE POSTURE/POLICIES 

- ADOPT Ada 

- CARRY OUT EVOLUTION TO S-O-A SOFTWARE PRACTICES 



MANAGEMENT QUESTIONS 
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RESPONSE SUMMARY 



AAS: FAA Advanced Automation System 



STANDARD PROGRAMMING 
LANGUAGE 



• Current major new business initiatives 

• Use on 2 programs is voluntary 

Members of Hughes staff involved in national Ada community. 



STANDARD PROGRAMMING 
LANGUAGE (cont'd) 




SOFTWARE ENGINEERING TASK 

FORCE 



Specify common avionics software functionality 



TAILORABLE STANDARDS FOR 
SOFTWARE DEVELOPMENT 
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COMMON SUPPORT ENVIRONMENT 



Host/Target System debugging capabilities 



CENTER PLANNING 
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CORE CURRICULUM IN SOFTWARE 

ENGINEERING 
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Training must be followed by use to be effective. 



RISK MANAGEMENT PLAN 



across compilers 



Ada INCENTIVE PROGRAM 
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SOFTWARE R&D SUPPORT FOR Ada 
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COLLECT SOFTWARE METRICS 
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IMPROVE DEVELOPMENT PROCESS 
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system will perform functionally, as required. 

Hughes accomplishing this via Engineering Councils, SPS, SEI 
participation. 



CONCLUSIONS 
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IBM Response to ASMAWG 
Recommendations 


31 May 1989 
Judy K. Fleming 


SID Houston 
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IBM Response to ASMAWG Recommendations 


IBM Response to ASMAWG 
Recommendations 

• General Observations 

• Ada Adoption 

• Software Engineering and Ada Implementation 
Task Force 

• Policies and Standards 

• Software Development Environments 

• Training 

• Risk Management 

• Contractor Incentives 

• Software Measurement Program 

• Summary 
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IBM-2 


31 May 1989 



General Observations 


General Observations 


• Common Experience within IBM 

o Similar growing pains, assessment of 
situation, plans to alleviate 

o Recognition of movement to new software 
engineering process (technologies and tools) 
as much as to new language 

• NASA role: acquire or perform Ada 
development? 

o ACQUISITION versus PERFORMANCE (viz. 

JSC) requires a different focus in training 
plan, standards, development environment 

o Monitoring, deliverables 

• SSFP implications: schedule acceleration, ideal 
testbed 

o Ada selection demonstrates ENORMOUS 
commitment by NASA 

o Opportunity to accelerate 5-year plan 
milestones 

o Existing mechanisms to attack several 
-objectives 

IBM ' 31 May 1989 
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General Observations 


• SSE Leverage 

o Use it as prototype development environment 
o Learn from it 

o Focus reuse and measurement activities on it 

• Build on considerable work already done by 
contractors, academia, SEI, DoD, STARS, etc. in 
most everything 

o Curriculum 

o Metrics 

o Reuse 

o Interface standards 
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Ada Adoption 


Ada Adoption 


• Establish strategy on use of pre-existing, 
non-Ada code and COTS software 

o Appropriate usage 

o Incorporation techniques 

• Identify acceptable special purpose languages 

o 4GLs for data base interfaces 

o Non-procedural languages for Al, expert 
systems 

• Use R&D effort to enhance coexistence of 
special languages with Ada 
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Software Engineering and Ada Implementation Task Force 


Software Engineering and Ada 
Implementation Task Force 


• Good mechanism to spread "lessons learned" 
across NASA 

o IBM's Ada Steering Group serves similar 
purpose: institutionalize what works well, 
discard what doesn't, share as much as 
possible 

• Could be NASA pipeline to DoD, SEI, STARS, 
etc. 

• IBM would like to participate 

o Infuse "LL" from FAA Advanced Automation 
System (large Ada program about three 
years ahead of SSFP) 

o Share recent work in tailoring procedures 


Policies and Standards 


Policies and Standards 


• Agree with idea of tailorable standards 

• Recommend agency-wide focus on review 
points (entry/exit criteria, especially "red flags"), 
measurements, reuse, deliverables and their 
format 
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Software Development Environments 


Software Development 
Environments 


• Ultimate prototype in process: SSE 

o NASA is too far down the pike to invest in 
another prototype 

o Learn from it and drive it (especially for 
metrics, reuse, ''integration" of software 
deliverables) 

• Good approach for common environment 

o Functional capabilities rather than specific 
tool set on specific platform 

o Recommend defining framework via interface 
specifications, as consistent with industry 
standards as practical (STARS is moving this 
way) 

o Concentrate on maintainability, portability, 
and reusability for NASA without limiting 
contractors in use of latest/greatest/favored 
tools and technology 
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Training 


Training 


• Reasonable approach 

• Additional project-specific education will be 
needed 

• Access to cadre of experts would enhance OJT, 
following classes 

o Ada Center of Competence 

o SWAT team 
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Risk Management 


Risk Management 

• Risk management plan required for SSFP 

• Add Ada-specific content 
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Contractor Incentives 


Contractor Incentives 


• Ada readiness is intrinsic to proposal evaluation 
process 

• Probably unnecessary this late in the game for 
NASA to "share" training costs 

• Focus on reuse incentives 

o Make it financially rewarding in the near-term 
to reuse rather than rebuild 

o As reuse becomes a way of life, contractors 
will naturally migrate to it to reduce costs 

o Currently, the more you build the more 
money you make! 

• Recognize life-cycle shifts implied by Ada, 
proper software engineering practices, reuse, 
prototyping 


Software Measurement Program 


Software Measurement Program 


• Drive SSE requirements to match NASA-wide 
needs 

o Plans exist for tool support of collection of 
wide range of software metrics 

• Involve JPL software cost engineering folks 

o Historical data (for flight systems) and a 
proven methodology for collection and 
analysis 

• Take advantage of SEI Measurement Task Force 
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Summary 


Summary 


• Leverage SSFP (and SSE) as data source and 
prototype 

• Capitalize on activities in larger Ada world 

o Spend NASA's money on space!!!! 

• Share experiences and institutionalize 
technology infusion 
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Addendum to IBM Response 


Addendum to IBM Response 


(Additional recommendations made during 

presentation) 

• Use NASA R&D (or other funding approach) to 
attack NASA-specific needs 

o Analysis tools such as those buiit for HAL on 
Shuttle (e.g., HALSTAT, disassembler, 
Simulation Data Files) 

o Simulation and testing interfaces (e.g., to 
allow data access during simulation 
executions) 

• More extensive knowledge of Ada within NASA 
would facilitate acceptance of the language in 
design articles and could thereby reduce 
documentation and review costs 

• Consider how many different development 
environments and unique tools NASA can afford 
to support for programs requiring long-term 
maintenance 
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NASA has a major opportunity to leverage on (if not join hands with) 
ongoing DoD initiatives in research, reuse, software metrics, process 
models, development standards, program office preparation, product 
and contractor assessment, and policy 

- Resulting commonality benefits NASA's contractors too 
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Questions About the Common Support 
Environment Recommendation 
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Does the recommended "standard requirements for deliverables" mean 
representations of all artifacts of development processes and their 
interrelationships (e.g., requirements traced to designs & code & tests. 
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Assistance to tool builders versus systems builders? 

Commercial supportability (maintenance) of the support 
environment? 


A Prioritization of Environment 
Objectives? 
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low payoff if not fulfilling other objectives 
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2. A DEFINITION OF FUNCTIONAL CAPABILITIES 


CONTRACTOR INCENTIVES 
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RESOLUTION OF LEGAL BARRIERS 
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